# Работа с багами
## Описание
Это процесс наполнения, приоритизации и разбора багов. Процесс позволяет сделать работу с багами понятной и прозрачной для команды.

## Почему ветка важна?
Баги в системе – это неправильное поведение системы. Слишком большое число критичных багов приводит к сильной деградации системы и в конечном счёте отражается на продуктовых метриках.

Что процесс даёт для разных ролей.
Для лида:
Контроль за состоянием системы. По динамике наполнения и разбора багов можно делать выводы как о проблемах в продукте, так и о работе команды разработчиков.

Для команды:
- Понятный план действий при обнаружении бага.
- Понимание, как неправильное поведение системы будет устраняться.

Для продукта и пользователей:
- Пользователи реже встречаются с неправильным поведением системы, а в критичных кейсах – почти никогда.
- Сообщения от пользователей становятся одной из входных точек процесса разбора багов.

## Что будет, если её не делать?
- Непонятно кто и когда будет его разбирать. Разное представление об этом можем вызывать конфликты в команде.
- В процессе разработки системы неизбежно появляются новые баги. Без процесса происходит неконтролируемая деградация.

## На кого может быть делегирована?
На старших QA-специалистов в команде или компании.
На Scrum-мастеров, продактов.

## Примеры поведения
### Примеры плохого поведения
- Найденные баги никуда не заводятся и, как следствие, никогда не исправляются.
- Как и куда заводить баги знают только QA-специалисты.
- Все найденные баги должны исправляться немедленно.
- Бэклог растёт значительно быстрее, чем разбирается.
- Задачи от начальства автоматически получают максимальный приоритет вне зависимости от их реальной критичности.
- В бэклоге много старых багов.

### Примеры хорошего поведения
- Каждый участник команды понимает, что делать при обнаружении бага.
- Регулярно выделяется время на разбор багов. Бэклог багов не пухнет.

## Способы прокачки
### Практика
У любой системы работы с багами есть несколько составляющих:
- Бэклог, куда баги заводятся и хранятся.
- Правила, по которым бэклог наполняется.
- Процесс, по которому бэклог разбирается.
- Люди, ответственные за наполнение и разбор багов.

Конфигурации могут быть разными и отличаться в зависимости от структуры команд.
Например, в случае с матричной структурой компании, за систему сбора багов и наполнение отвечает отдел QA. Разбор может проходить за счёт периодического разбора багов силами разработчиков. Бывают интересные варианты с [багодельней](https://habr.com/ru/company/avito/blog/351736/), когда баги разбираются в формате хакатона с элементами геймификации.

#### Zero Bug Policy
Основная критика многих стандартных подходов с наполнением и периодическим разбором багов в том, что он всё равно пухнет. Обычно так происходит из-за того, что создание новых фичей видится более перспективным для продактов, чем разбор старых багов. Просто выкидывать баги в силу специфики работы тестировщикам тоже не хочется. В итоге бэклог багов превращается в «антресоль», куда баги попадают, но из которой уже не достаются.

Идея Zero Bug Policy в том, что баги не хранить. Фактически предлагается баги раскладывать на две группы:
- Критичный, потому дёргаем стоп-кран и правим его в этом же спринте.
- Не столь критичный, потому забываем о нём. Если каждый такой баг складировать, бэклог будет только расти.

Опять же, это не означает, что мы снижаем планку качества. Мы признаем, что в нашем продукте есть сколько-то багов и это нормально.

Критика данного метода основывается на следующем:
- Команда QA может начать деградировать. Зачем упираться, если твой баг всё равно могут выкинуть?
- Выброшенные баги могут давать кумулятивный эффект и выстрелить при нахождении бага, который команда решит править.
- Нет источника информации по багам. Каждый раз баги находятся как с чистого листа.

## Консультации
- [Telegram-чат TL Bootcamp](https://tlinks.run/tlbootcamp).

## Теория
### Статьи

- [Ещё один взгляд на разбор багов](http://wolonter.blogspot.com/2018/01/blog-post_10.html)
- [Багодельня — марафон по убийству престарелых багов](https://habr.com/ru/company/avito/blog/351736/)
- [Багодельня: BUgHunting. Как найти 200 багов за день](https://habr.com/ru/company/avito/blog/453000/)
- [Zero Bug Policy. Нет багов — нет проблем?](https://habr.com/ru/company/avito/blog/455068/)
- [Best engineering practices: how to fix a bug?](https://sobolevn.me/2019/01/how-to-fix-a-bug)
- [#zerobugpolicy или как мы баги чиним](https://www.facebook.com/notes/dodo-pizza-engineering/zerobugpolicy-или-как-мы-баги-чиним/1446732912129727/)
